HDDS-14660. Implement new table to store part information for multipart uploads#9886
Conversation
ivandika3
left a comment
There was a problem hiding this comment.
Thanks @spacemonkd for the patch, overall LGTM. Left some comments,
ivandika3
left a comment
There was a problem hiding this comment.
Thanks for the update. LGTM +1.
|
What is the plan for layout management? Since on disk structures are changing. |
|
@kerneltime We are putting behind a gate check. When the upgrade is finalized then the client will populate Example gate: |
|
@kerneltime Any more comments? @rakeshadr PTAL |
rakeshadr
left a comment
There was a problem hiding this comment.
Thanks @spacemonkd for the patch. Added a few comments, please check it.
rakeshadr
left a comment
There was a problem hiding this comment.
Thanks @spacemonkd for the continuous efforts. LGTM +1
Please reply to the conservations and resolve it, then proceed with merge.
|
Thanks for the reviews @ivandika3 @rakeshadr. |
| final ByteBuffer uploadIdBuffer = input.duplicate(); | ||
| uploadIdBuffer.limit(separatorIndex); | ||
| uploadIdBuffer.position(start); | ||
| String uploadId = StandardCharsets.UTF_8.decode(uploadIdBuffer).toString(); |
There was a problem hiding this comment.
@spacemonkd , We should use StringCodec since UTF_8.decode(..) below uses CodingErrorAction.REPLACE. When there is an error, it will silently replace characters and cause unexpected behavior.
When there is an error, the correct behavior is to throw an exception. Filed HDDS-15348.
// java.nio.charset.Charset.java
public final CharBuffer decode(ByteBuffer bb) {
try {
return ThreadLocalCoders.decoderFor(this)
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE)
.decode(bb);
} catch (CharacterCodingException x) {
throw new Error(x); // Can't happen
}
}
What changes were proposed in this pull request?
HDDS-14660. Implement new table to store part information for multipart uploads
Please describe your PR in detail:
multipartPartsTableto handle storing of parts for Multipart Uploads.How is the PartKey encoded?
Say for the below sample input (we are taking 47 as it has 2F in the lower byte):
Encoding format:
keyBytes =
UTF8(uploadId)+/+int32_be(partNumber)For 47:
int32 big-endian bytes =
00 00 00 2fSo final tail is:
2f00 00 00 2f2f 00 00 00 2fNow we run the following checks:
A logical key will look something like the following in the RocksDB entry:
and will be represented as:
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-14660
How was this patch tested?
Patch has been tested by running unit tests.